Organization-based content rights management and systems, structures, and methods therefor

ABSTRACT

A method is employed to propagate rights management (RM) protection to an email and to an attachment thereof comprising an RM-protectable document. The email with the RM-protectable attachment is authored, and a content key (KD) and a bind ID are generated. RM protection is first applied to the RM-protectable attachment of the email based on the generated (KD) and the generated bind ID, and the RM-protected attachment is attached to the email. RM protection is then applied to the email with the attached RM-protected attachment based on the generated (KD) and the generated bind ID. The RM-protected email and the RM-protected attachment thereof thus share the generated (KD) and the generated bind ID such that a license obtained for the RM-protected email and having therein the generated bind ID and the generated (KD) can be applied to render the RM-protected email and also the RM-protected attachment thereof.

CROSS-REFERENCE TO RELATED APPLICATIONS

The following U.S. patent applications disclose subject matter that isrelated to the subject matter of the present application, and are herebyincorporated herein by reference in their entirety:

-   -   U.S. patent application Ser. No. ______, filed concurrently with        the present application under attorney docket number MSFT-2151        and entitled “Organization-Based Content Rights Management and        Systems, Structures, and Methods Therefor”;    -   U.S. patent application Ser. No. ______, filed concurrently with        the present application under attorney docket number MSFT-2152        and entitled “Organization-Based Content Rights Management and        Systems, Structures, and Methods Therefor”;    -   U.S. patent application Ser. No. ______, filed concurrently with        the present application under attorney docket number MSFT-2154        and entitled “Organization-Based Content Rights Management and        Systems, Structures, and Methods Therefor”;    -   U.S. patent application Ser. No. 10/185,527, filed Jun. 28, 2002        under attorney docket number MSFT-1330 and entitled “Obtaining a        Signed Rights Label (SRL) for Digital Content and Obtaining a        Digital License Corresponding to the Content Based on the SRL in        a Digital Rights Management System”;    -   U.S. patent application Ser. No. 10/185,278, filed Jun. 28, 2002        under attorney docket number MSFT-1333 and entitled “Using a        Rights Template to Obtain a Signed Rights Label (SRL) for        Digital Content in a Digital Rights Management System”;    -   U.S. patent application Ser. No. 10/185,511, filed Jun. 28, 2002        under attorney docket number MSFT-1343 and entitled “Systems And        Methods For Issuing Usage Licenses For Digital Content And        Services”;    -   U.S. patent application Ser. No. 10/364,627, filed Feb. 11, 2003        under attorney docket number MSFT-1498 and entitled “Publishing        Digital Content Within an Organization in Accordance with a        Digital Rights Management (RM) System; and    -   U.S. patent application Ser. No. 10/364,115, filed Feb. 11, 2003        under attorney docket number MSFT-1569 and entitled “Publishing        Digital Content Within an Organization in Accordance with a        Digital Rights Management (RM) System.

TECHNICAL FIELD

This invention relates to a rights management (RM) system. Moreparticularly, the invention relates to employing an RM system to publishdigital content in an organization such as an office or corporation orthe like such that rendering and use of the content within theorganization may be constrained according to corresponding use orlicense terms. Even more particularly, the present invention relates topublishing and rendering and using rights-managed content within theorganization including documents, databases, electronic mail, tables,and presentations.

BACKGROUND OF THE INVENTION

Rights management and enforcement is highly desirable in connection withdigital content such as digital audio, digital video, digital text,digital data, digital multimedia, etc., where such digital content is tobe distributed to one or more users. Digital content could be static,such as a text document, for example, or it could be streamed, such asthe streamed audio/video of a live event. Typical modes of distributioninclude tangible devices such as a magnetic (floppy) disk, a magnetictape, an optical (compact) disk (CD), etc., and intangible media such asan electronic bulletin board, an electronic network, the Internet, etc.Upon being received by the user, such user renders the digital contentwith the aid of appropriate rendering software such as an audio player,a text displayer, etc. on a personal computer or other hardware.

In one scenario, a content owner or rights-owner such as an author, apublisher, a broadcaster, etc., wishes to distribute such digitalcontent to each of many users or recipients in exchange for a licensefee or some other consideration. In such scenario, then, the content maybe an audio recording, a multimedia presentation, etc., and the purposeof the distribution is to generate the license fee. Such content owner,given the choice, would likely wish to restrict what the user can dowith such distributed digital content. For example, the content ownerwould like to restrict the user from copying and re-distributing suchcontent to a second user, at least in a manner that denies the contentowner a license fee from such second user.

In addition, the content owner may wish to provide the user with theflexibility to purchase different types of use licenses at differentlicense fees, while at the same time holding the user to the terms ofwhatever type of license is in fact purchased. For example, the contentowner may wish to allow distributed digital content to be rendered onlya limited number of times, only for a certain total time, only on acertain type of machine, only on a certain type of rendering platform,only by a certain type of user, etc.

In another scenario, a content developer, such as an employee in ormember of an organization, wishes to distribute such digital content toone or more other employees or members in the organization or to otherindividuals outside the organization, but would like to keep others fromrendering the content. Here, the distribution of the content is moreakin to organization-based content sharing in a confidential orrestricted manner, as opposed to broad-based distribution in exchangefor a license fee or some other consideration.

In such scenario, then, the content may be a document presentation,spreadsheet, database, email, or the like, such as may be exchangedwithin an office setting, and the content developer may wish to ensurethat the content stays within the organization or office setting and isnot rendered by non-authorized individuals, such as for examplecompetitors or adversaries. Again, such content developer wishes torestrict what a recipient can do with such distributed digital content.For example, the content owner would like to restrict the user fromcopying and re-distributing such content to a second user, at least in amanner that exposes the content outside the bounds of individuals whoshould be allowed to render the content.

In addition, the content developer may wish to provide variousrecipients with different levels of rendering rights. For example, thecontent developer may wish to allow protected digital content to beviewable and not printable with respect to one class of individual, andviewable and printable with respect to another class of individual.

However, and in either scenario, after distribution has occurred, suchcontent owner/developer has very little if any control over the digitalcontent. This is especially problematic in view of the fact thatpractically every personal computer includes the software and hardwarenecessary to make an exact digital copy of such digital content, and todownload such exact digital copy to a writeable magnetic or opticaldisk, or to send such exact digital copy over a network such as theInternet to any destination.

Of course, as part of a transaction wherein the content is distributed,the content owner/developer may require the user/recipient of thedigital content to promise not to re-distribute such digital content inan unwelcome manner. However, such a promise is easily made and easilybroken. A content owner/developer may attempt to prevent suchre-distribution through any of several known security devices, usuallyinvolving encryption and decryption. However, there is likely verylittle that prevents a mildly determined user from decrypting encrypteddigital content, saving such digital content in an un-encrypted form,and then re-distributing same.

RM and enforcement architectures and methods have thus been provided toallow the controlled rendering of arbitrary forms of digital content,where such control is flexible and definable by the contentowner/developer of such digital content. Examples of such architecturesare set forth in the related applications set forth above, among,others. Such architectures allow and facilitate such controlledrendering, especially in an office or organization environment or thelike where documents are to be shared amongst a defined group ofindividuals or classes of individuals.

A need exists, however, for various systems, structures, and methods inconnection with such architectures to effectuate various RM functions.

SUMMARY OF THE INVENTION

The aforementioned needs are satisfied at least in part by the presentinvention in which a method is employed to propagate rights management(RM) protection to an email and to an attachment of the email, where theattachment comprises an RM-protectable document. In the method, theemail with the RM-protectable attachment is authored, and a content key(KD) and a bind ID are generated.

RM protection is first applied to the RM-protectable attachment of theemail based on the generated (KD) and the generated bind ID, and theRM-protected attachment is attached to the email. RM protection is thenapplied to the email with the attached RM-protected attachment based onthe generated (KD) and the generated bind ID. The RM-protected email andthe RM-protected attachment thereof thus share the generated (KD) andthe generated bind ID such that a license obtained for the RM-protectedemail and having therein the generated bind ID and the generated (KD)can be applied to render the RM-protected email and also theRM-protected attachment thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description ofthe embodiments of the present invention, will be better understood whenread in conjunction with the appended drawings. For the purpose ofillustrating the invention, there are shown in the drawings embodimentswhich are presently preferred. As should be understood, however, theinvention is not limited to the precise arrangements andinstrumentalities shown. In the drawings:

FIG. 1 is a block diagram representing an exemplary non-limitingcomputing environment in which the present invention may be implemented;

FIG. 2 is a block diagram representing an exemplary network environmenthaving a variety of computing devices in which the present invention maybe implemented;

FIG. 3 is a block diagram showing an enforcement architecture of anexample of a trust-based system;

FIG. 4 is a block diagram showing the structure of an RM-protected emailsuch as may be used in the system of FIG. 3 in accordance with oneembodiment of the present invention;

FIG. 5 is a flow diagram showing key steps performed by an emailapplication in attempting to render the RM-protected email of FIG. 4 inaccordance with one embodiment of the present invention;

FIG. 6 is a flow diagram showing key steps performed in issuing alicense for the email of FIG. 4 and rendering such email based on suchlicense in accordance with one embodiment of the present invention;

FIG. 7 is a flow diagram showing key steps performed in RM-protectingthe email of FIG. 4 in accordance with one embodiment of the presentinvention;

FIG. 8 is a flow diagram showing key steps performed in propagatingRM-protection to attachments of the email of FIG. 4 in accordance withone embodiment of the present invention;

FIG. 9 is a flow diagram showing key steps performed in acquiring alicense with a decryption key (KD) for the email of FIG. 4 in accordancewith one embodiment of the present invention;

FIG. 10 is a block diagram showing the structure of an RM-protecteddocument such as may be used in the system of FIG. 3 in accordance withone embodiment of the present invention;

FIG. 11 is a flow diagram showing key steps performed by a documentapplication in attempting to render the RM-protected document of FIG. 10in accordance with one embodiment of the present invention;

FIG. 12 is a block diagram showing the structure of a document storethat dynamically applies RM protection to documents requested therefromin accordance with one embodiment of the present invention;

FIG. 13 is a flow diagram showing key steps performed in connection withthe document store of FIG. 12 in accordance with one embodiment of thepresent invention;

FIG. 14 is a block diagram showing the structure of a conversationwithin the body of an email;

FIG. 15 is a block diagram showing the conversation of FIG. 14 asRM-protected body objects within the body of an RM-protected email inaccordance with one embodiment of the present invention;

FIG. 16 is a block diagram showing a document with the RM-protected bodyobjects of FIG. 15 therein in accordance with one embodiment of thepresent invention; and

FIG. 17 is a flow diagram showing key steps performed in decommissioningthe RM server of FIG. 3 and removing RM protection from correspondingprotected content in accordance with one embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

Computer Environment

FIG. 1 and the following discussion are intended to provide a briefgeneral description of a suitable computing environment in which theinvention may be implemented. It should be understood, however, thathandheld, portable, and other computing devices of all kinds arecontemplated for use in connection with the present invention. While ageneral purpose computer is described below, this is but one example,and the present invention requires only a thin client having networkserver interoperability and interaction. Thus, the present invention maybe implemented in an environment of networked hosted services in whichvery little or minimal client resources are implicated, e.g., anetworked environment in which the client device serves merely as abrowser or interface to the World Wide Web.

Although not required, the invention can be implemented via anapplication programming interface (API), for use by a developer, and/orincluded within the network browsing software which will be described inthe general context of computer-executable instructions, such as programmodules, being executed by one or more computers, such as clientworkstations, servers, or other devices. Generally, program modulesinclude routines, programs, objects, components, data structures and thelike that perform particular tasks or implement particular abstract datatypes. Typically, the functionality of the program modules may becombined or distributed as desired in various embodiments. Moreover,those skilled in the art will appreciate that the invention may bepracticed with other computer system configurations. Other well knowncomputing systems, environments, and/or configurations that may besuitable for use with the invention include, but are not limited to,personal computers (PCs), automated teller machines, server computers,hand-held or laptop devices, multi-processor systems,microprocessor-based systems, programmable consumer electronics, networkPCs, minicomputers, mainframe computers, and the like. The invention mayalso be practiced in distributed computing environments where tasks areperformed by remote processing devices that are linked through acommunications network or other data transmission medium. In adistributed computing environment, program modules may be located inboth local and remote computer storage media including memory storagedevices.

FIG. 1 thus illustrates an example of a suitable computing systemenvironment 100 in which the invention may be implemented, although asmade clear above, the computing system environment 100 is only oneexample of a suitable computing environment and is not intended tosuggest any limitation as to the scope of use or functionality of theinvention. Neither should the computing environment 100 be interpretedas having any dependency or requirement relating to any one orcombination of components illustrated in the exemplary operatingenvironment 100.

With reference to FIG. 1, an exemplary system for implementing theinvention includes a general purpose computing device in the form of acomputer 110. Components of computer 110 may include, but are notlimited to, a processing unit 120, a system memory 130, and a system bus121 that couples various system components including the system memoryto the processing unit 120. The system bus 121 may be any of severaltypes of bus structures including a memory bus or memory controller, aperipheral bus, and a local bus using any of a variety of busarchitectures. By way of example, and not limitation, such architecturesinclude Industry Standard Architecture (ISA) bus, Micro ChannelArchitecture (MCA) bus, Enhanced ISA (EISA) bus, Video ElectronicsStandards Association (VESA) local bus, and Peripheral ComponentInterconnect (PCI) bus (also known as Mezzanine bus).

Computer 110 typically includes a variety of computer readable media.Computer readable media can be any available media that can be accessedby computer 110 and includes both volatile and nonvolatile media,removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media includes both volatileand nonvolatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CDROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by computer 110. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared, and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer readable media.

The system memory 130 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 131and random access memory (RAM) 132. A basic input/output system 133(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 110, such as during start-up, istypically stored in ROM 131. RAM 132 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 120. By way of example, and notlimitation, FIG. 1 illustrates operating system 134, applicationprograms 135, other program modules 136, and program data 137.

The computer 110 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 1 illustrates a hard disk drive 141 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 151that reads from or writes to a removable, nonvolatile magnetic disk 152,and an optical disk drive 155 that reads from or writes to a removable,nonvolatile optical disk 156, such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 141 is typically connectedto the system bus 121 through a non-removable memory interface such asinterface 140, and magnetic disk drive 151 and optical disk drive 155are typically connected to the system bus 121 by a removable memoryinterface, such as interface 150.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 1 provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 110. In FIG. 1, for example, hard disk drive 141 is illustratedas storing operating system 144, application programs 145, other programmodules 146, and program data 147. Note that these components can eitherbe the same as or different from operating system 134, applicationprograms 135, other program modules 136, and program data 137. Operatingsystem 144, application programs 145, other program modules 146, andprogram data 147 are given different numbers here to illustrate that, ata minimum, they are different copies. A user may enter commands andinformation into the computer 110 through input devices such as akeyboard 162 and pointing device 161, commonly referred to as a mouse,trackball or touch pad. Other input devices (not shown) may include amicrophone, joystick, game pad, satellite dish, scanner, or the like.These and other input devices are often connected to the processing unit120 through a user input interface 160 that is coupled to the system bus121, but may be connected by other interface and bus structures, such asa parallel port, game port or a universal serial bus (USB).

A monitor 191 or other type of display device is also connected to thesystem bus 121 via an interface, such as a video interface 190. Agraphics interface 182, such as Northbridge, may also be connected tothe system bus 121. Northbridge is a chipset that communicates with theCPU, or host processing unit 120, and assumes responsibility foraccelerated graphics port (AGP) communications. One or more graphicsprocessing units (GPUs) 184 may communicate with graphics interface 182.In this regard, GPUs 184 generally include on-chip memory storage, suchas register storage and GPUs 184 communicate with a video memory 186.GPUs 184, however, are but one example of a coprocessor and thus avariety of co-processing devices may be included in computer 110. Amonitor 191 or other type of display device is also connected to thesystem bus 121 via an interface, such as a video interface 190, whichmay in turn communicate with video memory 186. In addition to monitor191, computers may also include other peripheral output devices such asspeakers 197 and printer 196, which may be connected through an outputperipheral interface 195.

The computer 110 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer180. The remote computer 180 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the computer 110, although only a memory storage device 181 has beenillustrated in FIG. 1. The logical connections depicted in FIG. 1include a local area network (LAN) 171 and a wide area network (WAN)173, but may also include other networks. Such networking environmentsare commonplace in offices, enterprise-wide computer networks, intranetsand the Internet.

When used in a LAN networking environment, the computer 110 is connectedto the LAN 171 through a network interface or adapter 170. When used ina WAN networking environment, the computer 110 typically includes amodem 172 or other means for establishing communications over the WAN173, such as the Internet. The modem 172, which may be internal orexternal, may be connected to the system bus 121 via the user inputinterface 160, or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the computer 110, orportions thereof, may be stored in the remote memory storage device. Byway of example, and not limitation, FIG. 1 illustrates remoteapplication programs 185 as residing on memory device 181. It will beappreciated that the network connections shown are exemplary and othermeans of establishing a communications link between the computers may beused.

One of ordinary skill in the art can appreciate that a computer 110 orother client device can be deployed as part of a computer network. Inthis regard, the present invention pertains to any computer systemhaving any number of memory or storage units, and any number ofapplications and processes occurring across any number of storage unitsor volumes. The present invention may apply to an environment withserver computers and client computers deployed in a network environment,having remote or local storage. The present invention may also apply toa standalone computing device, having programming languagefunctionality, interpretation and execution capabilities.

Distributed computing facilitates sharing of computer resources andservices by direct exchange between computing devices and systems. Theseresources and services include the exchange of information, cachestorage, and disk storage for files. Distributed computing takesadvantage of network connectivity, allowing clients to leverage theircollective power to benefit the entire enterprise. In this regard, avariety of devices may have applications, objects or resources that mayinteract to implicate authentication techniques of the present inventionfor trusted graphics pipeline(s).

FIG. 2 provides a schematic diagram of an exemplary networked ordistributed computing environment. The distributed computing environmentcomprises computing objects 10 a, 10 b, etc. and computing objects ordevices 110 a, 110 b, 110 c, etc. These objects may comprise programs,methods, data stores, programmable logic, etc. The objects may compriseportions of the same or different devices such as PDAs, televisions, MP3players, televisions, personal computers, etc. Each object cancommunicate with another object by way of the communications network 14.This network may itself comprise other computing objects and computingdevices that provide services to the system of FIG. 2. In accordancewith an aspect of the invention, each object 10 or 110 may contain anapplication that might request the authentication techniques of thepresent invention for trusted graphics pipeline(s).

It can also be appreciated that an object, such as 110 c, may be hostedon another computing device 10 or 110. Thus, although the physicalenvironment depicted may show the connected devices as computers, suchillustration is merely exemplary and the physical environment mayalternatively be depicted or described comprising various digitaldevices such as PDAs, televisions, MP3 players, etc., software objectssuch as interfaces, COM objects and the like.

There are a variety of systems, components, and network configurationsthat support distributed computing environments. For example, computingsystems may be connected together by wireline or wireless systems, bylocal networks or widely distributed networks. Currently, many of thenetworks are coupled to the Internet, which provides the infrastructurefor widely distributed computing and encompasses many differentnetworks.

In home networking environments, there are at least four disparatenetwork transport media that may each support a unique protocol such asPower line, data (both wireless and wired), voice (e.g., telephone) andentertainment media. Most home control devices such as light switchesand appliances may use power line for connectivity. Data Services mayenter the home as broadband (e.g., either DSL or Cable modem) and areaccessible within the home using either wireless (e.g., HomeRF or802.11b) or wired (e.g., Home PNA, Cat 5, even power line) connectivity.Voice traffic may enter the home either as wired (e.g., Cat 3) orwireless (e.g., cell phones) and may be distributed within the homeusing Cat 3 wiring. Entertainment media may enter the home eitherthrough satellite or cable and is typically distributed in the homeusing coaxial cable. IEEE 1394 and DVI are also emerging as digitalinterconnects for clusters of media devices. All of these networkenvironments and others that may emerge as protocol standards may beinterconnected to form an intranet that may be connected to the outsideworld by way of the Internet. In short, a variety of disparate sourcesexist for the storage and transmission of data, and consequently, movingforward, computing devices will require ways of protecting content atall portions of the data processing pipeline.

The ‘Internet’ commonly refers to the collection of networks andgateways that utilize the TCP/IP suite of protocols, which arewell-known in the art of computer networking. TCP/IP is an acronym for“Transport Control Protocol/Interface Program.” The Internet can bedescribed as a system of geographically distributed remote computernetworks interconnected by computers executing networking protocols thatallow users to interact and share information over the networks. Becauseof such wide-spread information sharing, remote networks such as theInternet have thus far generally evolved into an open system for whichdevelopers can design software applications for performing specializedoperations or services, essentially without restriction.

Thus, the network infrastructure enables a host of network topologiessuch as client/server, peer-to-peer, or hybrid architectures. The“client” is a member of a class or group that uses the services ofanother class or group to which it is not related. Thus, in computing, aclient is a process, i.e., roughly a set of instructions or tasks, thatrequests a service provided by another program. The client processutilizes the requested service without having to “know” any workingdetails about the other program or the service itself. In aclient/server architecture, particularly a networked system, a client isusually a computer that accesses shared network resources provided byanother computer e.g., a server. In the example of FIG. 2, computers 110a, 110 b, etc. can be thought of as clients and computer 10 a, 10 b,etc. can be thought of as the server where server 10 a, 10 b, etc.maintains the data that is then replicated in the client computers 110a, 110 b, etc.

A server is typically a remote computer system accessible over a remotenetwork such as the Internet. The client process may be active in afirst computer system, and the server process may be active in a secondcomputer system, communicating with one another over a communicationsmedium, thus providing distributed functionality and allowing multipleclients to take advantage of the information-gathering capabilities ofthe server.

Client and server communicate with one another utilizing thefunctionality provided by a protocol layer. For example,Hypertext-Transfer Protocol (HTTP) is a common protocol that is used inconjunction with the World Wide Web (WWW). Typically, a computer networkaddress such as a Universal Resource Locator (URL) or an InternetProtocol (IP) address is used to identify the server or client computersto each other. The network address can be referred to as a UniversalResource Locator address. For example, communication can be providedover a communications medium. In particular, the client and server maybe coupled to one another via TCP/IP connections for high-capacitycommunication.

Thus, FIG. 2 illustrates an exemplary networked or distributedenvironment, with a server in communication with client computers via anetwork/bus, in which the present invention may be employed. In moredetail, a number of servers 10 a, 10 b, etc., are interconnected via acommunications network/bus 14, which may be a LAN, WAN, intranet, theInternet, etc., with a number of client or remote computing devices 110a, 110 b, 110 c, 110 d, 110 e, etc., such as a portable computer,handheld computer, thin client, networked appliance, or other device,such as a VCR, TV, oven, light, heater and the like in accordance withthe present invention. It is thus contemplated that the presentinvention may apply to any computing device in connection with which itis desirable to process, store or render secure content from a trustedsource.

In a network environment in which the communications network/bus 14 isthe Internet, for example, the servers 10 can be Web servers with whichthe clients 110 a,110 b, 110 c, 110 d,110 e, etc. communicate via any ofa number of known protocols such as HTTP. Servers 10 may also serve asclients 110, as may be characteristic of a distributed computingenvironment. Communications may be wired or wireless, where appropriate.Client devices 110 may or may not communicate via communicationsnetwork/bus 14, and may have independent communications associatedtherewith. For example, in the case of a TV or VCR, there may or may notbe a networked aspect to the control thereof. Each client computer 110and server computer 10 may be equipped with various application programmodules or objects 135 and with connections or access to various typesof storage elements or objects, across which files may be stored or towhich portion(s) of files may be downloaded or migrated. Thus, thepresent invention can be utilized in a computer network environmenthaving client computers 110 a, 110 b, etc. that can access and interactwith a computer network/bus 14 and server computers 10 a, 10 b, etc.that may interact with client computers 110 a, 110 b, etc. and otherdevices 111 and databases 20.

Rights Management (RM) Overview

As is known, and referring now to FIG. 3, rights management (RM) andenforcement is highly desirable in connection with digital content 32such as digital audio, digital video, digital text, digital data,digital multimedia, etc., where such digital content 32 is to bedistributed to users. Upon being received by the user, such user rendersthe digital content with the aid of an appropriate rendering device suchas a media player, text displayer, etc. on a personal computer 34 or thelike.

Typically, a content owner or developer (hereinafter ‘owner’)distributing such digital content 32 wishes to restrict what the usercan do with such distributed digital content 32. For example, thecontent owner may wish to restrict the user from copying andre-distributing such content 32 to a second user, or may wish to allowdistributed digital content 32 to be rendered only a limited number oftimes, only for a certain total time, only on a certain type of machine,only on a certain type of rendering platform, only by a certain type ofuser, etc.

However, after distribution has occurred, such content owner has verylittle if any control over the digital content 32. An RM system 30,then, allows the controlled rendering of arbitrary forms of digitalcontent 32, where such control is flexible and definable by the contentowner of such digital content. Typically, content 32 is distributed tothe user in the form of a package 33 by way of any appropriatedistribution channel. The digital content package 33 as distributed mayinclude the digital content 32 encrypted with a symmetricencryption/decryption key (KD), (i.e., (KD(CONTENT))), as well as otherinformation identifying the content, how to acquire a license for suchcontent, etc.

The trust-based RM system 30 allows an owner of digital content 32 tospecify license rules that must be satisfied before such digital content32 is allowed to be rendered on a user's computing device 34. Suchlicense rules can include the aforementioned temporal requirement, andmay be embodied within a digital license or use document (hereinafter‘license’) 36 that the user/user's computing device 34 (hereinafter,such terms are interchangeable unless circumstances require otherwise)must obtain from the content owner or an agent thereof. Such license 36also includes the decryption key (KD) for decrypting the digitalcontent, perhaps encrypted according to a key decryptable by the user'scomputing device 34. As seen in FIG. 3, such encrypting key is a publickey of the user's computing device 34 (PU-BB), and the user's computingdevice 34 presumably has the corresponding private key (PR-BB) by which(PU-BB(KD)) may be decrypted.

The content owner for a piece of digital content 32 must trust that theuser's computing device 34 will abide by the rules and requirementsspecified by such content owner in the license 36, i.e. that the digitalcontent 32 will not be rendered unless the rules and requirements withinthe license 36 are satisfied. Preferably, then, the user's computingdevice 34 is provided with a trusted component or mechanism 38 that willnot render the digital content 32 except according to the license rulesembodied in the license 36 associated with the digital content 32 andobtained by the user.

The trusted component 18 typically has a license evaluator 40 thatdetermines whether the license 36 is valid, reviews the license rulesand requirements in such valid license 36, and determines based on thereviewed license rules and requirements whether the requesting user hasthe right to render the requested digital content 32 in the mannersought, among other things. As should be understood, the licenseevaluator 40 is trusted in the RM system 30 to carry out the wishes ofthe owner of the digital content 32 according to the rules andrequirements in the license 36, and the user should not be able toeasily alter such trusted element for any purpose, nefarious orotherwise.

As should be understood, the rules and requirements in the license 36can specify whether the user has rights to render the digital content 32based on any of several factors, including who the user is, where theuser is located, what type of computing device the user is using, whatrendering application is calling the RM system, the date, the time, etc.In addition, the rules and requirements of the license 36 may limit thelicense 36 to a pre-determined number of renderings, or pre-determinedrendering time, for example. Thus, the trusted component 38 may need torefer to a clock 42 on the computing device 34.

The rules and requirements may be specified in the license 36 accordingto any appropriate language and syntax. For example, the language maysimply specify attributes and values that must be satisfied (DATE mustbe later than X, e.g.), or may require the performance of functionsaccording to a specified script (IF DATE greater than X, THEN DO . . . ,e.g.).

Upon the license evaluator 40 determining that the license 36 is validand that the user satisfies the rules and requirements therein, thedigital content 32 can then be rendered. In particular, to render thecontent 32, the decryption key (KD) is obtained from the license 36 andis applied to (KD(CONTENT)) from the content package 33 to result in theactual content 32, and the actual content 32 is then in fact rendered.

Rights-Managed Electronic Mail

As may be appreciated, especially within an organization, it isdesirable to apply rights management and enforcement to electroniccommunications between individuals within the organization, such as forexample electronic mail messages (‘email’) between such individuals.Accordingly, each individual in the organization that receives such anemail and the content 32 therein can in fact so render such content 32,assuming that the individual obtains a license 36 corresponding to theemail content 32 and that the rules and requirements of the obtainedlicense 36 in fact allow the individual to so render. Correspondingly,an individual inside or outside the organization that receives such anemail and the content 32 therein cannot render such content 32 if suchindividual cannot obtain a license 36 corresponding to the email content32, or if the rules and requirements of the obtained license 36 do notin fact allow the individual to so render.

In one embodiment of the present invention, then, an individual in anorganization sending email can apply RM to protect the content 32 of theemail such that the protection travels with the email. Thus, even if theemail is forwarded from one recipient to another, either inside oroutside the organization, the content 32 of the email can only berendered by a recipient that can obtain a license 36 for the content 32,where the license 36 allows such recipient to in fact render the content32 of the email. It may be the case that only recipients within theorganization can get such a license 36, although it is to be appreciatedthat other recipients may be granted such a license 36 without departingfrom the spirit and scope of the present invention. For example, theprotection traveling with the email may allow a non-organizationrecipient to obtain a license 36 as a ‘guest’ or the like, and thelicense 36 may be for the guest recipient to read the content 32 only.

As may be appreciated, the license 36 for the email content 32 istypically obtained from an RM server 54 (FIG. 3) operated by or onbehalf of the organization. Such license 36 may be sent with the emailunder at least some circumstances, may be obtained upon opening theemail, may be obtained upon downloading the email, may be obtained atthe direction of the recipient, and/or the like, all without departingfrom the spirit and scope of the present invention. Moreover, suchobtaining may be performed manually or automatically if circumstancesallow, again without departing from the spirit and scope of the presentinvention.

Significantly, inasmuch as the email with the protected content 32 maybe received by an RM-compliant individual with a trusted component 38and the like, such email should be in a form amenable to suchRM-compliant individual. At the same time, inasmuch as the email withthe protected content 32 may be received by a non-RM-compliantindividual without a trusted component 38 and the like, such emailshould also be in a form amenable to such non-RM-compliant individual,at least to the extent that the email is recognizable as such by thecomputing device of the non-RM-compliant individual, informs thenon-compliant individual of the protected content 32 therein and doesnot inappropriately affect the computing device of the non-RM-compliantindividual. Put another way, the email with the protected content 32should be in a more-or-less standard email form so as to be recognizedas email, but should also include within the standard form the protectedcontent 32 of the email along with all necessary RM-related information.

Thus, in one embodiment of the present invention, the structure of anRM-protected email message is consistent with a MIME or MAPIrepresentation of an email message with an attachment. Further, in suchembodiment, the attachment includes protected content 32 of the emailalong with other RM-related information. For the sake of simplicity, asomewhat generalized MIME or MAPI structure for an email is set forth:

-   -   HEADER    -   MAIN INFO        -   AS PLAIN TEXT        -   AS HTML        -   AS OTHER    -   ATTACHMENT(S)

As may be appreciated, the HEADER portion contains basic informationrelating to the email, including a date, any subject information, thesender, the recipient, and/or the like. The MAIN INFO portion containsthe body of the email, which may include text, pictures, links, and/orthe like. Notably, inasmuch as some recipients may have different emailcapabilities, the MAIN INFO portion can include several alternativeversions of the body of the email, including the body AS PLAIN TEXT fora recipient that cannot handle anything more complex than plain text,and the body AS HTML for a recipient that can handle more complex HTML(Hyper Text Markup Language) formatting. Of course, other alternativeversions of the body may also be included, such as for example a versionwith the body in an XML (extensible Markup Language) format.

The ATTACHMENT portion can contain most any information that a senderwishes to attach to an email, such as for example one or more files, orone or more other pieces of information to be included with the email.In the latter category, such other piece of information may for exampleinclude specific information that the sender wishes to send to therecipient but that does not fit elsewhere within the email.

In one embodiment of the present invention, then, and referring now toFIG. 4, the aforementioned email structure is employed to sendRM-compliant email 44, as follows. In particular, and as seen in FIG. 4,in the embodiment, the email 44 contains the protected content 32 asbeing embedded within an attachment 46 to the email 44, and the trustedcomponent 38 and the email application on the computing device 34 of anRM-compliant individual are aware that such protected content 32 is inthe attachment 46.

Of course, such protected content 32 in the attachment 46 is of no useto a non-RM-compliant individual and an email application thereof at acomputing device thereof, and accordingly the main info 48 of the email44 may contain a message to the effect that the email 44 is RM-protectedand therefore not viewable by the non-RM-compliant individual.Alternatively, the main info 48 of the email 44 may have anothermessage, an advertisement, a link for more information on RM-compliantemail 44, etc. Note that in the case where the trusted component 38 andthe email application on the computing device 34 of an RM-compliantindividual are aware that such protected content 32 is in the attachmentand can access such protected content 32, it may be the case that themessage in the main info 48 of the email 44 is bypassed entirely and isnot displayed to the RM-compliant individual. Instead, the protectedcontent 32 in the attachment is displayed upon the approval of thetrusted component 38 and decryption of such protected content 32. Thetrusted component 38 and the email application on the computing device34 of an RM-compliant individual may become aware that the protectedcontent 32 is in the attachment in any appropriate manner withoutdeparting from the spirit and scope of the present invention. Forexample, in examining the attachment 44 of the email 46 certainidentifying indicia may be found.

In one embodiment of the present invention, and as also seen in FIG. 4,the attachment 46 of the email 44 with the protected content 32 isorganized in the following manner. In general, the attachment 46 has theprotected content 32 and also has rights data 50 relating to theprotected content 32. As may be appreciated, the rights data 50 may bedefined by the sender of the email or may be defined by a templateselected by the sender of the email, and sets forth each individual orgroup of individuals that has rights with respect to the protectedcontent 32, and for each such individual or group of individuals adescription of such rights. Thus, and as an example, the rights mayspecify that one particular individual can read, print, and forward theemail and copy the contents of same for an unlimited duration, but thata particular group of individuals may only read and reply to the emailfor the next seven days. Note that the individuals or groups ofindividuals set forth in the rights data 50 may extend beyond the scopeof the recipients of the email 44, based on the assumption that suchrecipients may forward the email 44 to other recipients.

Significantly, and as was set forth above, the protected content 32 inthe attachment 46 of the email 44 is encrypted according to acryptographic key, and the rights data 50 may include a decryption key(KD) for decrypting the encrypted content 32. Of course, such decryptionkey (KD) should itself be encrypted to prevent unauthorized use thereof.Accordingly, in one embodiment of the present invention, the decryptionkey (KD) in the rights data 50 is encrypted according to a public key ofthe aforementioned RM server 54 (PU-RM) operated by or on behalf of theorganization to result in (PU-RM(KD)). Alternatively, the rights data 50is encrypted according to a public key of the sender (PU-SE) to resultin (PU-SE(KD)) and only the aforementioned RM server 54 can gain accessto a corresponding private key of the sender (PR-SE). Thus, only the RMserver 54 having the private key (PR-RM) corresponding to (PU-RM) oraccess to (PR-SE) can apply same to (PU-RM(KD)) or (PU-SE(KD)) from therights data 50 to obtain (KD). Alternatively, only the sender having theprivate key (PR-SE) corresponding to (PU-SE) can apply same to(PU-SE(KD)) from the rights data 50 to obtain (KD).

As may be appreciated, the RM server 54 in fact obtains (KD) from therights data 50 in the course of creating the aforementioned license 36for the protected content 32 and places such (KD) into the license 36,perhaps encrypted according to a key decryptable by the user's computingdevice 34. Alternatively, the sender in fact obtains (KD) from therights data 50 in the course of creating the aforementioned license 36for the protected content 32 and places such (KD) into the license 36,perhaps encrypted according to a key decryptable by the user's computingdevice 34. As should be understood, the sender should be able to createa license 36 for itself without the aid of the RM server 54 so that suchsender can render its own protected content 32.

Still referring to FIG. 4, it is seen that the protected content 32 inthe attachment 46 of the email 44 may actually comprise severalalternative forms of the body of the email 44, which again may includetext, pictures, links, and/or the like. As before, the alternative formsmay be provided inasmuch as some recipients may have different emailcapabilities. As shown, some of the alternative forms may include thebody in plain text, in HTML, in XML, in rich text format (RTF), in plaintext as HTML, etc. Of course, other alternative versions of the body mayalso be included in the protected content 32 without departing from thespirit and scope of the present invention. Note that the protectedcontent 32 may also include body information, such as for examplewhether the body is included in plain text or in HTML, and other bodyinformation.

Finally, the protected content 32 may also include attachments to thebody of the email 44, which inasmuch as the body of the email 44 isitself part of the attachment 46, will hereinafter be referred to asprotected content attachments 52. As may be appreciated, such protectedcontent attachments 52 may be organized in any particular manner withoutdeparting from the spirit and scope of the present invention. Forexample, in one scenario, the attachments 52 may be organized into alist that also includes as a preface or the like the number ofattachments 52 and the name of each attachment 52, and includes as apostscript or the like metadata relating to the addenda, if any.

In one embodiment of the present invention, the protected/encryptedcontent 32 of the email 44 is compressed to reduce the overall sizethereof. As may be appreciated, the trusted component 38 may decompressthe encrypted and compressed content 32 in the course of decryptingsame. As may also be appreciated, such compression provides asignificant reduction in the overall size of the email 44 having theprotected content 32 in the attachment 46 thereof. Notably, suchcompression is not presently found by default in existing email formats.

With the email 44 created by a sender thereof as set forth herein andsent to a recipient, then, and turning now to FIG. 5, the recipient uponreceiving same (step 501) processes such email 44 in the followingmanner.

In the case where the recipient and the computing device 34 thereof arenot enabled, such recipient and the computing device 34 thereof open theemail 44 (step 503). In doing so, and inasmuch as the non-RM-enabledrecipient cannot access the protected content 32 therein let alonerecognize that the email 44 has such protected content 32 therein, themain info 48 of the email 44 is displayed to the recipient, where suchmain info 48 is the message that the email 44 is RM-protected and thatthe recipient does not have rights to view the body of such email 44(step 505). In addition, the attachment 46 is identified to thenon-RM-enabled recipient, even though such recipient would not be ableto decrypt the protected content 32 therein (step 507). Thus, the email44 as received by the non-RM-enabled recipient is handled in the samemanner as any other email 44 that would be received by suchnon-RM-enabled recipient, except for the fact that the message deliveredin the email 44 is that the recipient cannot view the body of such email44 as is set forth in the protected content 32 therein.

In the case where the recipient and the computing device 34 thereof arein fact enabled, such recipient and the computing device 34 thereof alsoopen the email 44 (step 509). Here, though, the RM-enabled recipient infact recognizes that the email 44 has protected content 32 therein (step511), discounts the main info 48 of the email 44 (step 513), and insteadexamines the attachment 46 of the email 44 and proceeds based thereon torender the protected content 32 for the RM-compliant recipient (step515).

Any appropriate methods and mechanisms may be employed to render theprotected content 32 for the RM-compliant recipient without departingfrom the spirit and scope of the present invention. For example, and inone embodiment of the present invention, and turning now to FIG. 6, therights data 50 in the attachment 46 of the email 44 is retrieved andforwarded to the RM server 54 (step 601), and such RM server 54determines that the RM-compliant recipient is one of the individuals orin one of the groups of individuals listed in the rights data 50 (step603) and thereafter issues a license 36 corresponding to the protectedcontent 32 to the recipient based on the rights data 50 (step 605),where such license 36 specifies the rights the recipient has withrespect to the protected content 32 as determined from the rights data50, and also includes from the rights data 50 a decryption key (KD) fordecrypting the encrypted content 32. As was set forth above, such (KD)may be encrypted in a manner decryptable by the trusted component 18 ofthe computing device 34 of the recipient.

The trusted component 38 of the computing device 34 of the RM-compliantrecipient then reviews the issued license 36 to determine that therecipient has the right to view the content 32 (step 607), andthereafter retrieves (KD) from the license 36 and the protected content32 from the email 44 (step 609), decrypts the protected content 32 with(KD) (step 611), and presents the decrypted content 32 for rendering(step 613). Note that based on the rights the recipient has with respectto the content 32 as set forth in the license 36, the trusted component38 may take other appropriate actions. For example, if the recipientdoes not have the right to copy or print the content 32, the trustedcomponent 38 would direct the email application to turn off suchfunctions with respect to such content 32.

As should now be appreciated, in the present invention, rightsmanagement is applied to an email 44 by way of a trusted component 18 ona computing device 34 of a RM-compliant recipient, and the email 44 isin a form that is still recognizable to a non-RM-compliant recipient asemail 44, even though such non-RM-compliant recipient cannot access theprotected content 32 in such email 44. Moreover, inasmuch as theprotected content 32 is rights managed, such content 32 can becompressed within the email 44 and decompressed by the trusted component18.

Propagating RM Protection to Attachments 52 of RM-Protected Email 44

As may be appreciated, although an email 44 may now be RM-protected, forexample in the manner set forth above, such RM protection does notautomatically extend to any attachments 52 thereof. That is, if anattachment 52 of the email 44, such as for example a word processingdocument, is not itself RM-protected, the RM protection of the email 44does not automatically protect the attachment 52 once the email 44 hasbeen rendered by a recipient thereof. Accordingly, and without such RMprotection, the attachment 52 may be freely and widely distributed incontravention of the goals and purposes of RM.

Thus, and in one embodiment of the present invention, each attachment 52of an email 44 is RM-protected upon RM-protecting the email 44 itself,presuming that such attachment 52 is capable of being RM-protected andhas not already been RM-protected. That is, each attachment 52 isRM-protected, but only if such attachment 52 is of a class of items thatRM-protection can be applied to. For example, it may be that the trustedcomponent 38 of the computing device 34 of the sender of the email 44can apply RM-protection to a word processing document of a certain type,but not to a word processing document of another type. If an attachment52 is already RM-protected, applying further RM-protection is not donesince to do so could remove more restrictive RM-protection.

RM protection may be applied to an RM-protectable item in anyappropriate manner without departing from the spirit and scope of thepresent invention. In one embodiment of the present invention, RMprotection is applied by ‘publishing’ the item. Such publishing mayoccur at any appropriate time, such as when sending or saving the emailwith the item. Briefly, to publish the item, and turning now to FIG. 7,the trusted component 38 or another element on the computing device 34generates a content key (KD) that is used to encrypt the item (step701). The content key (KD) is typically a symmetric key although any keycan be used to encrypt the digital content. As is known, a symmetric keyis employed by a symmetric key algorithm both to encrypt and decrypt.Accordingly, (KD) should be well-hidden when shared between a sender anda receiver.

Thereafter, the item is encrypted with (KD) to form (KD(item)) (step703). Additionally, rights data 50 corresponding to (KD(item)) isgenerated (step 705), either by the publisher of the content or byanother entity. Note that such rights data 50 may be custom rights dataor rights data as obtained from a pre-defined template. As was discussedabove, the rights data 50 can include a list of entities that will beentitled to consume the content, the specific rights that each of theentities possesses with respect to the content, and any conditions thatmay be imposed on those rights.

(KD(item)) is then protected to the aforementioned RM server 54 so thatall license requests are directed to such RM server 54. In particular, apublic key of the RM server 54 (PU-RM) is employed to encrypt (KD) toresult in (PU-RM(KD)) (step 707). Thus, only the RM server 54 with thecorresponding private key (PR-RM) can decrypt same to reveal (KD).Additionally, the rights data 50 for the items may also be encrypted by(KD) or (PU-RM), although such encrypted rights data 50 may not beperceived as necessary in all cases.

Thereafter, the rights data 50 is submitted to the RM server 54 forsigning, or can be self-signed if permission to do so is given by the RMserver 54 (step 709). As may be appreciated, the signed rights data 50is tamper-resistant in that any changes to the signed rights data 50will cause the corresponding signature to fail to verify.

Significantly, and in one embodiment of the present invention, the itemis provided with a bind ID at some point in the process (step 711), andsuch bind ID may be included with the signed rights data 50 (step 713).Thus, when the rights data 50 is employed to obtain a license 36 for theitem as in FIG. 6, such license 36 also includes the bind ID and thus istied or bound to such item thereby.

Once the signed rights data 50 is obtained, such signed rights data 50is concatenated with the corresponding (KD(item)) to form a package 33containing the RM-protected item (step 715). Thus, a renderingapplication that is RM-enabled can discover the signed rights data 50upon attempting to render the package 33, and such discovery triggersthe rendering application to initiate a license request against the RMserver 54 as in FIG. 6. Note that with regard to an RM-protected email44, the package 33 is in actuality the attachment 46 of the email 44 asshown in FIG. 4, where the protected content 32 of the attachment 45 is(KD(item)) and where the rights data 50 of the attachment 46 is thesigned rights data 50.

With the understanding, then, that an email 44 may be RM-protected in amanner such as that shown in FIG. 7, and also that an attachment of suchemail 44 may also be RM-protected in a manner such as that shown in FIG.7, a method of propagating RM-protection from an email 44 to eachRM-protectable attachment 52 thereof is set forth.

In particular, and turning now to FIG. 8, it is presumed that a senderhas authored an email 44 with an RM-protectable attachment 52 (step801), but that RM protection has not as yet been applied to the email 44or to the attachment 52. Prior to sending or otherwise saving the email44 with the attachment 52, then, the sender selects rights data 50 forthe email 44, either from a menu of rights data choices or from a menuavailable templates of such rights data 50 (step 803), and actuatesapplication of RM protection to the email 44 (step 805). Significantly,in the course of actuating application of RM protection to the email 44,a particular bind ID and a particular content decryption key (KD) areselected for the email 44 and each RM-protectable attachment thereof(step 807).

In one embodiment of the present invention, prior to applying RMprotection to the email 44 itself, RM protection is first applied toeach RM-protectable and not already protected attachment 52 of the email44 (step 809), where such RM protection is applied in a manner akin tothat shown in FIG. 7. Accordingly, each attachment 52 is transformedinto a package 33 with a (KD(item)) based on the particular (KD), signedrights data 50, and the particular item ID. Thereafter, each suchpackage 33 is attached to the email 44 as a corresponding attachment 52(step 810), and RM protection is then applied to the email 44 itself(step 811), where such RM protection is again applied in a manner akinto that shown in FIG. 7. Accordingly, the email 44 with each attachment52 is transformed into a structure such as that shown in FIG. 4, and hasa (KD(item)) based on the particular (KD), signed rights data 50, andthe particular item ID.

Thus, and significantly, and in one embodiment of the present invention,all of the RM-protected attachments 52 and the RM-protected email 44itself share the same particular content decryption key (KD) and thesame particular bind ID. Accordingly, and as should be appreciated, alicense 36 obtained for the email 44 in the manner shown in FIG. 6 willhave the particular bind ID of the email 44 and also of all of theRM-protected attachments 52 of the email, and will also have theparticular decryption key (KD) that decrypts the email 44 and also ofall of the RM-protected attachments 52 of the email.

As may now be appreciated, by having all of the RM-protected attachments52 and the RM-protected email 44 itself share the same particularcontent decryption key (KD) and the same particular bind ID, a recipientof the email 44 needs only a single license 36 to render all of suchRM-protected attachments 52 and such RM-protected email 44 itself,presuming of course the single license 36 delivers such rendering rightsto such recipient. Moreover, such single license 36 has a single set ofrights data 50 that is applicable to the email 44 and all of theRM-protected attachments 52 thereof, and accordingly it can be said thatthe rights attached to the email 44 as embodied in the correspondingsingle license 36 have been propagated to each RM-protected attachment52 of such email 44. It should of course be understood that onlyattachments 52 protected as a result of being included in a protectede-mail 44 share the license 36. Previously-protected attachments 52included in the email 44 require an additional license 36.

Note, though, that the single license 36 cannot be specific to anyparticular item from among the email 44 and the attachments 52 thereofsuch that the single license 36 is not applicable to all of such items.Note, too, that in RM protecting each item, as at steps 809 and 811 ofFIG. 8, only a single set of the rights data 50 need be generated andsubmitted, as at steps 705 and 709 of FIG. 7, to result in a single setof signed rights data 50, inasmuch as the single license 36 is generatedfrom the single set of rights data, as is shown in FIG. 6. Nevertheless,each item from among the email 44 and the attachments 52 thereof shouldbe in a package 33 with the single set of signed rights data 50 inasmuchas any attachment 52 within the email 44 may potentially be separatedfrom such email and redistributed to another recipient, and such anotherrecipient needs such signed rights data 50 to obtain another license 36.

Acquiring Decryption Key for RM-Protected Email 44

As was set forth above, to render the protected content 32 in anRM-protected email 44 such as that shown in FIG. 4, where the protectedcontent 32 is encrypted according to a content key (KD), a recipient ofthe email 44 must obtain a corresponding license 36 with (KD) from theRM server 54, satisfy the rights and conditions set forth in the license36, obtain (KD) from the license 36, and apply (KD) to decrypt theprotected content 32 in such email 44, all in a manner such as thatshown in FIG. 6. However, and significantly, the RM server 54 is likelyonly available to the recipient of the email 44 by way of a network orthe like, and it can be the case that the recipient is not alwaysconnectively coupled to such RM server 54 by way of such network. Thatis, it may be the case that the recipient is connectively coupled to thenetwork to receive the email 44, and does not at such time obtain acorresponding license 36 for the protected content 32 in the email 44.

Thus, it may be the situation that the recipient of the email 44 islater out of network connectivity with the RM server 54 and thereforecannot obtain the corresponding license 36 with (KD) to render theprotected content 32 of the email 44. Accordingly, and in one embodimentof the present invention, the email application 56 and the trustedcomponent 38 in combination work to automatically obtain a license 36for each email 44 with protected content 32 therein when such email isfirst received by the recipient and such recipient is connectivelycoupled to the network and to the RM server 54 thereby.

In particular, and turning now to FIG. 9, in one embodiment of thepresent invention, while connectively coupled to the network of thelike, the email application 56 of the recipient receives an email 44(step 901) and recognizes that the received email 44 has protectedcontent 32 therein (step 903). As was set forth above, the emailapplication 56 may determine that the email 44 has protected content 32therein by way of any appropriate method or mechanism without departingfrom the spirit and scope of the present invention. Thereafter, theemail application 56 and the trusted component 38 work together toobtain a license 36 for the protected content 32 of the email 44 fromthe RM server 54 while the computing device 34 of the trusted component38 is still remains connectively coupled to the network by which the RMserver 54 may be accessed (step 905).

In one embodiment of the present invention, the email application 56 ofthe recipient may be presumed to be capable of receiving several emails44 at a time, especially if the emails 44 are received from an emailserver (not shown) that must be polled for such emails 44. Accordingly,and in such embodiment, the email application 56 places each receivedemail 44 with protected content 32 therein into a queue 58 (FIG. 3)(step 905-1), and the trusted component 38 retrieves the received email44 from the queue 58 (step 905-3), and requests the license 36 for theprotected content 32 of the retrieved email 44 (step 905-5), preferablyin an automatic manner, in a manner transparent to the recipient, and ina manner such as that shown in FIG. 6.

Note that it may be the case that the trusted component 38 can beexpected to request a license 36 from any of one or more RM servers 54,where a request is directed to a particular RM server 54 based on RMserver information in the corresponding content 32. In such situation,and in appreciation of the fact that at various times each RM server 54may fail to respond to such a request for a license 36, and in oneembodiment of the present invention, the trusted component 38 maymaintain a bad server list 60 in which a non-responding or ‘bad’ RMserver 54 may be entered (step 905-7).

Of course, a bad RM server 54 can be expected to be fixed within areasonable period of time, on the order of five to thirty minutes or so,and accordingly, the trusted component 38 may include a process thatremoves each entered bad RM server 54 from the list 60 in acorresponding amount of time. Accordingly, a request for a license 36 ismade to a particular RM server 54 as at step 905-5, but only if the RMserver 54 that the request is directed to is not on the bad server list60. If such RM server 54 is indeed on the bad server list 60, thecorresponding email 44 may be placed back into the queue 58 for laterprocessing (step 905-9), on the presumption that the RM server 54 willeventually be removed from the list 60, or may be discarded from thequeue 58 and simply not be licensed by way of the queue 58 (step905-11).

Note, that in the case where RM protection has been propagated toattachments 52 of email 44, as is the case in connection with FIG. 8,the license 36 that has been obtained by the process of FIG. 9 appliesnot only to the email 44 but to all of the protected attachments 52thereof. Accordingly, and again, only one license request need be madeper email 44.

Note, too, that the invention of FIG. 9 has up until now been set forthin terms of obtaining a license 36 when a corresponding email 44 withprotected content 32 is obtained, such invention is not limited to suchemail 44. Instead, it should be appreciated that the invention of FIG. 9may also be employed to obtain a license 36 when any protected content32 is obtained, especially in the case where the protected content 32 isreceived over a network and it is possible that the recipient may loseconnectivity with such network.

As should now be appreciated, in employing the method of the presentinvention as set forth in FIG. 9, the trusted component 38 of thecomputing device 34 of the recipient automatically requests andhopefully obtains a license 36 for protected content 32 in an email 44or from any other network source when the trusted component 38 iscommunicatively coupled to the network. Thus, the trusted component 38as communicatively coupled to the network can automatically contact anappropriate RM server 54 thereon in the course of requesting suchlicense 36. As a result, the license 36 as automatically obtained ispresent on the computing device 34 and may be employed to render theprotected content 32 even in the case where the computing device 34 isout of communication with the network at some later time.

Rights-Managed Document

In a manner similar to an email 44, and as may be appreciated, it isespecially desirable within an organization to apply rights managementand enforcement to documents such as electronic word processingdocuments. Accordingly, each individual in an organization that receivessuch a word processing document or other document with protected content32 therein can in fact so render such content 32, again assuming thatthe individual obtains a license 36 corresponding to the content 32 andthat the rules and requirements of the obtained license 36 in fact allowthe individual to so render. Correspondingly, an individual inside oroutside the organization that receives such a word processing documentor other document and the content 32 therein cannot render such content32 if such individual cannot obtain a license 36 corresponding to thecontent 32, or if the rules and requirements of the obtained license 36do not in fact allow the individual to so render.

In one embodiment of the present invention, then, an individual in anorganization constructing such a word processing document or otherdocument can apply RM to protect the content 32 of the document suchthat the protection travels with the document. Thus, even if thedocument is forwarded from one recipient to another, either inside oroutside the organization, the content 32 of the document can only berendered by a recipient that can obtain a license 36 for the documentcontent 32, where the license 36 allows such recipient to in fact renderthe content 32 of the document. It may be the case that only recipientswithin the organization can get such a license 36, although it is to beappreciated that other recipients may be granted such a license 36without departing from the spirit and scope of the present invention.For example, the protection traveling with the document may allow anon-organization recipient to obtain a license 36 as a ‘guest’ or thelike, and the license 36 may be for the guest recipient to read thecontent 32 only.

As may be appreciated, the license 36 for the document content 32 istypically obtained from an RM server 54 (FIG. 3) operated by or onbehalf of the organization. Such license 36 may be sent with thedocument under at least some circumstances, may be obtained upon openingthe document, may be obtained upon downloading the document, may beobtained at the direction of the recipient, and/or the like, all withoutdeparting from the spirit and scope of the present invention. Moreover,such obtaining may be performed manually or automatically ifcircumstances allow, again without departing from the spirit and scopeof the present invention.

Significantly, inasmuch as the document with the protected content 32may be received by an RM-compliant individual with a trusted component38 and the like, such document should be in a form amenable to suchRM-compliant individual. At the same time, inasmuch as the document withthe protected content 32 may be received by a non-RM-compliantindividual without a trusted component 38 and the like, such documentshould also be in a form amenable to such non-RM-compliant individual,at least to the extent that the document is recognizable as such by thecomputing device of the non-RM-compliant individual, informs thenon-compliant individual of the protected content 32 therein and doesnot inappropriately affect the computing device of the non-RM-compliantindividual. Put another way, the document with the protected content 32should be in a more-or-less standard document form so as to berecognized as a document, but should also include within the standardform the protected content 32 of the email along with all necessaryRM-related information.

Thus, in one embodiment of the present invention, the structure of anRM-protected document such as a word processing document is consistentwith the structure of a non-RM-protected document with a custom datasection therein. Further, in such embodiment, the custom data sectionincludes protected content 32 of the document along with otherRM-related information. For the sake of simplicity, a somewhatgeneralized non-RM-protected document structure is set forth:

-   -   DOCUMENT PROPERTIES    -   CUSTOM PROPERTIES    -   STORAGE    -   CUSTOM DATA

As may be appreciated, the DOCUMENT PROPERTIES portion contains basicinformation relating to the document, perhaps including an author, acreation date, and other parameters by which the document can beindexed. The CUSTOM PROPERTIES portion contains properties informationthat is not especially of interest to a user or the like and is notespecially useful for indexing purposes but may be of use to anotherapplication. For example, such custom properties information maycomprise content tagged according to an XML format for use by theanother application. The STORAGE portion contains the body of thedocument, which may include text, pictures, links, and/or the like.

In a manner similar to email, inasmuch as the document may be renderedby different document applications, the document can include alternativeversions of the body of the document. Here, however, the differentversions are set forth within the CUSTOM DATA portion. More generally,the CUSTOM DATA portion can contain most any kind of information that isor can be made available to another application that may wish to accessthe document. Thus, the CUSTOM DATA portion may contain sections withalternative versions of the body of the document for such anotherapplication, may contain sections with other information, documentation,content, etc. for use by another application, may contain sections withextra data for use by an extension of an application, and/or the like.

In one embodiment of the present invention, then, and referring now toFIG. 10, the aforementioned document structure is employed to send andRM-compliant document 62 such as a word processing document, as follows.In particular, and as seen in FIG. 10, in the embodiment, the document62 contains the RM-protected content 32 as being embedded within asection 64 of the custom data 66 of the document 62, and the trustedcomponent 38 and the document application 56 on the computing device 34of an RM-compliant individual are aware that such protected content 32is in the section 64 of the custom data 66.

Of course, such protected content 32 in the custom data 66 is of no useto a non-RM-compliant individual and a document application thereof at acomputing device thereof, and accordingly the storage 68 of the document62 may contain a message to the effect that the document 62 isRM-protected and therefore not viewable by the non-RM-compliantindividual. Alternatively, the storage 68 of the document 62 may haveanother message, an advertisement, a link for more information on theRM-compliant document 62, etc. Note that the document application couldbe employed to alter the message in the storage 68 unless such storage68 is password-protected to in effect lock the message.

Note too that in the case where the trusted component 38 and thedocument application 56 on the computing device 34 of an RM-compliantindividual are aware that such protected content 32 is in the customdata 66 and can access such protected content 32, it may be the casethat the message in the storage 68 of the document 62 is bypassedentirely and is not displayed to the RM-compliant individual. Instead,the protected content 32 in the custom data 66 is displayed upon theapproval of the trusted component 38 and decryption of such protectedcontent 32. The trusted component 38 and the document application 56 onthe computing device 34 of an RM-compliant individual may become awarethat the protected content 32 is in the custom data 66 in anyappropriate manner without departing from the spirit and scope of thepresent invention. For example, in examining the section 64 of thecustom data 66 of the document 62 with the protected content 32, certainidentifying indicia may be found.

The protected content 32 in the custom data 66 may be in any particularformat without departing from the spirit and scope of the presentinvention. For example, the protected content 32 may comprise encrypteddata in a format specific to the document application 56, or maycomprise encrypted data in a format not specific to the documentapplication 56. In the latter case, such format may for example compriseHTML, RTF, or an XML-based format. Note that with regard to HTML, XML,and the like, a rights-managed viewer application may be provided toallow an individual to view such protected content 32 while at the sametime making it more difficult to edit such protected content 32, ifindeed editing is even allowed.

In one embodiment of the present invention, and as also seen in FIG. 10,in addition to a section 64 of the custom data 66 of the document 62with the protected content 32 therein, the custom data 66 has anothersection 64 with rights data 50 relating to the protected content 32.Similar to before, the rights data 50 may be defined by the author ofthe document 62 or may be defined by a template selected by the authorof the document 62, and sets forth each individual or group ofindividuals that has rights with respect to the protected content 32,and for each such individual or group of individuals a description ofsuch rights. Thus, and as an example, the rights may specify that oneparticular individual can read and print the document 62 and copy thecontents of same for an unlimited duration, but that a particular groupof individuals may only read the document 62 for the next seven days.Presumably, then, the document 62 may be distributed and re-distributedto any number of individuals.

As with email, the protected content 32 in the custom data 66 of thedocument 62 is encrypted according to a cryptographic key, and therights data 50 may include a decryption key (KD) for decrypting theencrypted content 32. Of course, such decryption key (KD) should itselfbe encrypted to prevent unauthorized use thereof. Accordingly, in oneembodiment of the present invention, the decryption key (KD) in therights data 50 is encrypted according to a public key of theaforementioned RM server 54 (PU-RM) operated by or on behalf of theorganization to result in (PU-RM(KD)). Alternatively, the rights data 50is encrypted according to a public key of the author (PU-AU) to resultin (PU-AU(KD)) and only the aforementioned RM server 54 can gain accessto a corresponding private key of the author (PR-AU). Thus, only the RMserver 54 having the private key (PR-RM) corresponding to (PU-RM) oraccess to (PR-AU) can apply same to (PU-RM(KD)) or (PU-AU(KD)) from therights data 50 to obtain (KD). Alternatively, only the author having theprivate key (PR-AU) corresponding to (PU-AU) can apply same to(PU-AU(KD)) from the rights data 50 to obtain (KD).

As may be appreciated, the RM server 54 in fact obtains (KD) from therights data 50 in the course of creating the aforementioned license 36for the protected content 32 and places such (KD) into the license 36,perhaps encrypted according to a key decryptable by the user's computingdevice 34. Alternatively, the sender in fact obtains (KD) from therights data 50 in the course of creating the aforementioned license 36for the protected content 32 and places such (KD) into the license 36,perhaps encrypted according to a key decryptable by the user's computingdevice 34. As should be understood, the sender should be able to createa license 36 for itself without the aid of the RM server 54 so that suchsender can render its own protected content 32.

In one embodiment of the present invention, the protected/encryptedcontent 32 of the document 62 is compressed to reduce the overall sizethereof. As may be appreciated, the trusted component 38 may decompressthe encrypted and compressed content 32 in the course of decryptingsame. As may also be appreciated, such compression provides asignificant reduction in the overall size of the document 62 having theprotected content 32 in the custom data 66 thereof. Notably, suchcompression is not presently found by default in existing documentformats.

With the document 62 created by an author thereof as set forth hereinand forwarded to another individual, then, and turning now to FIG. 11,the receiving individual upon receiving same (step 1101) processes suchdocument 62 in the following manner.

In the case where the recipient and the computing device 34 thereof arenot enabled, such recipient and the computing device 34 thereof open thedocument 62 (step 1103). In doing so, and inasmuch as the non-RM-enabledrecipient cannot access the protected content 32 therein let alonerecognize that the document 62 has such protected content 32 therein,the storage 68 of the document 62 is displayed to the recipient, wheresuch storage 62 is the message that the document 62 is RM-protected andthat the recipient does not have rights to view the protected content 32of such document 62 (step 1105). Here, the sections 64 of the customdata 66 of the document 62 with the rights data 50 and the protectedcontent 32 are not normally identified to the non-RM-enabled recipient,although it is presumed that a determined recipient could find same.Nevertheless, such determined recipient would not be able to decrypt theprotected content 32 therein. Thus, the document 62 as received by thenon-RM-enabled recipient is handled in the same manner as any otherdocument 62 that would be received by such non-RM-enabled recipient,except for the fact that the message in the storage 68 of the document44 is that the recipient cannot view the protected content 32 of suchdocument 62 as is set forth in the custom data 66 therein.

In the case where the recipient and the computing device 34 thereof arein fact enabled, such recipient and the computing device 34 thereof alsoopen the document 62 (step 1109). Here, though, the RM-enabled recipientin fact recognizes that the document 62 has protected content 32 therein(step 1111), discounts the storage 68 of the document 62 (step 1113),and instead examines the sections 64 of the custom data 66 with therights data 50 and the protected content 32 and proceeds based thereonto render the protected content 32 for the RM-compliant recipient (step1115).

As before, any appropriate methods and mechanisms may be employed torender the protected content 32 for the RM-compliant recipient withoutdeparting from the spirit and scope of the present invention. Forexample, a method similar to that shown in FIG. 6 may be employed.

In one embodiment of the present invention, each license 36 obtained forcorresponding protected content 32 in the custom data 66 of the document62 is placed into the custom document 62 in another section 64 of thecustom data 66. Thus, each license 36 travels with a corresponding pieceof protected content 32 in a document 62, and the protected content 32in a document 62 may travel with multiple licenses 36.

In one embodiment of the present invention, the custom data 66 hasanother section 64 with transforms 70 that specify to a documentapplication 56 or the like how to get at the protected content 32. Inparticular, such transforms 70 may have a RM part specifying eachsection 64 of custom data 66 that is encrypted and each section 64 ofcustom data with a license 36 by which a decryption key (KD) may beobtained. In addition, such transforms 70 may have a compression partspecifying each section 64 of custom data 66 that is compressed and howthe section is compressed. Of course, the transforms 70 may have otherparts with other accessing information without departing from the spiritand scope of the present invention.

As should now be appreciated, in the present invention, rightsmanagement is applied to a document 62 by way of a trusted component 18on a computing device 34 of a RM-compliant recipient, and the document62 is in a form that is still recognizable to a non-RM-compliantrecipient as a document 62, even though such non-RM-compliant recipientcannot access the protected content 32 in such document 62. Moreover,inasmuch as the protected content 32 is rights managed, such content 32can be compressed within the document 62 and decompressed by the trustedcomponent 18.

Dynamically Applying RM Protection to Document in Document Store

RM protection has heretofore been discussed in terms of a particularindividual within an organization or the like creating some sort ofcontent and then protecting same prior to distributing the content toanother individual within the organization. However, it may also be thecase that a particular individual within an organization or the likecreates a document with some sort of content therein and then merelyplaces the document in an unprotected form in a document store managedby or on behalf of the organization. In such a situation, then, and inone embodiment of the present invention, the document store in responseto a request for the document from an individual has the responsibilityto respond to such request by determining that the requesting individualhas the right to access such document, by RM-protecting the document,and then by delivering the RM-protected document to the requestingindividual.

In connection with the document store of the present invention, then,and turning now to FIG. 12, it may be presumed that such document store72 stores a plurality of documents 74 in some sort of logicalarrangement, such as one or more folders 76 and sub-folders 76(hereinafter, ‘folders’) or the like. Significantly, and in oneembodiment of the present invention, for each folder 76, the documentstore 72 handles all documents 74 within the folder 76 in a like mannerwith respect to RM protection. Accordingly, an individual defines the RMprotection to be applied to a document 74 by placing the document 74 ina particular folder 76 based on the particular folder 76 having apredefined set of rights associated therewith. Again, each document 74within a particular folder 76 is not RM-protected, but RM-protection isapplied to a copy of the document 74 by the document store 72 when thecopy of the document 74 is delivered to a requesting individual.

Typically, each folder 76 has access controls 78 associated therewith,such as read-only, read-write, all rights, and the like, where theaccess controls are defined for each individual and/or for each group ofindividuals that may access the contents of the folder 76. In oneembodiment of the present invention, such access controls 78 as definedfor a requesting individual are employed to define the RM-protectionthat is to be applied to each copy of a document 74 delivered to suchrequesting individual. Thus, it may be the case that read-only accesswould translate to view-only RM protection rights, read-write accesswould translate to view, edit, save, and copy RM protection rights, andall rights would translate to view, edit, save, copy, print, savelocally, and change or delete RM protection rights.

In another embodiment of the present invention, in addition to or as analternative to setting RM-protection for the documents 74 of a folder 76by way of the access controls 78 for the folder 76, RM-protection mayalso be set by defining a specific rights template 80 to be associatedwith the folder 76. Such rights template 80 may have any particularrights defined therein without departing from the spirit and scope ofthe present invention, and may for example be common to every document74 within the folder 76, or may treat different types of documents 76within the folder 76 differently. In the latter case, for example, therights template 80 for a particular folder 76 may specify one set ofrights for word processing documents 74 and another set for spreadsheetdocuments 74, may specify one set of rights for documents 74 below acertain size and another set for documents 74 above a certain size,and/or the like.

Note that in contrast with propagated RM protection in an email 44 asset forth above, in dynamically applying RM protection to a document 74in a folder 76 in a document store 72, each document 76 is assigned aunique bind ID. Accordingly, a license 36 issued for a particulardocument 74 with a particular bind ID cannot be employed in connectionwith any other document 74 inasmuch all other documents 74 have adifferent bind ID.

Note, too, that RM-protection as set for a folder 76, either by way ofaccess controls 78 or by way of a rights template 80, may be changedfrom time to time by an administrator of the document store 72 or thelike. Accordingly, it may be the case that an individual may request adocument 74 from a folder 76 of the document store 72 and receive suchdocument 74 with a first set of rights data 50, and then some time laterunder identical circumstances may request the same document 74 from thesame folder 76 of the document store 72 and receive such document 74with a second set of rights data 50 different from the first set.

Turning now to FIG. 13, a method of using the document store 72 isshown. In such method, and as seen, the process begins by an individualstoring a document 74 in a folder 76 of the document store 72 (step1301). Presumptively, the individual storing the document 74 in thefolder 76 has access rights to do so, as defined by the access controls78 for the folder 76 or elsewhere. As was set forth above, such documentas stored in the document store 72 need not be encrypted inasmuch as RMprotection will be applied to a copy of the document 74 by the documentstore 72 when the copy is delivered to a requesting individual. Also,the document store 72 is presumptively secure against attacks bynefarious entities wishing to gain direct access to documents 72 in suchdocument store 72. Of course, encryption may nevertheless be applied tothe document 74 when storing same without departing from the spirit andscope of the present invention. Note again that by storing a document 74in a particular folder 76 of the document store 72, the storingindividual determines the RM-protection that is to be applied to thedocument 74 when retrieved from such particular folder 76 of suchdocument store 72.

At some time after the document 74 is stored in the folder 76 of thedocument store 72, the document store 72 receives a request for a copyof the requested document 74 from an individual (step 1303). Note herethat the requesting individual may be any individual who has accessrights to make a request, as defined by the access controls 78 for thefolder 76 or elsewhere. Upon receiving the request, the document storechecks the access controls 78 for the folder 76 to determine whether therequesting individual has rights that allow the document store 72 todeliver thereto a copy of the requested document 72. If not, the requestis denied and the process halts.

Otherwise, the process continues by the document store 72 mapping theaccess controls 78 for the folder 76 into RM rights that are to bedefined in rights data 50 for the copy of the requested document 72(step 1305). Such mapping may be performed in any appropriate mannerwithout departing from the spirit and scope of the present invention.Performing such mapping is known or should be apparent to the relevantpublic and therefore need not be defined herein in any detail.Significantly, in mapping the access controls 78, RM rights are definedin rights data 50 not only for the requesting individual but for allother individuals or groups of individuals specified in such accesscontrols 78. Accordingly, and as will be appreciated, the copy of therequested document 74 with the rights data 50 attached thereto can bedistributed and redistributed to such other individuals, and each suchother individual can employ the rights data 50 to obtain a license 36 torender the document 74.

In addition to or in the alternative to mapping the access controls 78for the folder 76 into rights data 50 for the copy of the requesteddocument 74, the document store 72 also determines whether the folder 76also has any rights template 80 associated therewith and if so thedocument store 72 copies at least a portion of the rights template 80for the folder 76 into the RM rights that are to be defined in rightsdata 50 for the copy of the requested document 72 (step 1309). Note thatthe document store 72 may copy the entire rights template 80 if deemedadvisable, or may copy only a portion of the rights template 80 that isrelevant to the copy of the requested document 72. For example, if thedocument is a word processing document 74 and the rights template 80specifies sets of rights for a number of kinds of documents 74 includingword processing documents 74, only the word processing set of rightsneed be copied, absent other considerations.

Once the rights data 50 for the copy of the requested document 74 havebeen defined, the document store 72 may then publish the copy of therequested document 74 in a manner similar to that shown in FIG. 7. Inparticular, the document store 72 by way of a trusted component 38associated therewith generates a content key (KD) and encrypts the copyof the requested document 74 with same to form (KD(copy)) (step 1311).(KD(copy)) is then protected to an RM server 54 so that all licenserequests are directed to such RM server 54. In particular, a public keyof the RM server 54 (PU-RM) is employed to encrypt (KD) to result in(PU-RM(KD)) (step 1313), and the defined rights data 50 with such(PU-RM(KD)) is submitted to the RM server 54 for signing, or can beself-signed if permission to do so is given by the RM server 54 (step1315).

Once the signed rights data 50 is obtained, such signed rights data 50is concatenated with the corresponding (KD(copy)) to form a package 33containing the RM-protected copy of the requested document 74 (step1317), and such package 33 is then delivered to the requestingindividual (step 1319). Thus, a rendering application of the requestingindividual that is RM-enabled can discover the signed rights data 50upon attempting to render the package 33, and such discovery triggersthe rendering application to initiate a request for a correspondinglicense 36 against the RM server 54 based on the signed rights data 50,as in FIG. 6. Alternatively, the document store 72 may obtain thelicense 36 from the RM server 54 on behalf of the requesting individualand deliver the obtained license 36 to the requesting individual withthe package 33 (step 1321).

RM-Protected Email Conversations

RM protection of an email 44 has heretofore been discussed in terms of asingle email 44, and has not as yet taken into account that an email 44may be a ‘originating’ email 44 that is replied by the recipient to thesender and/or may be forwarded by the recipient to another recipient. Ineither of such situations, and as should be appreciated, and as seen inFIG. 14, it is oftentimes useful and/or desirable to include a copy ofthe body of the originating email 44 with the reply or forward email 44so that an email thread or conversation 82 is developed. Thus, theconversation 82 may appear in an ‘omega’ email 44 and comprise therein abody 83 and a plurality of previously sent and received emails 44 thatare available to a recipient of the omega email 44 for easy reference.As may be appreciated, the conversation 82 within an email 44 can extendback an indefinite number of links of originating emails 44 to an‘alpha’ email 44 that started the conversation 82.

However, it is also to be appreciated as a dilemma that if anoriginating email 44 within a conversation 82 is RM-protected, suchprotected email 44 should not be rendered in the conversation 82, atleast for a recipient of the conversation 82 that does not have theright to render such protected email 44. One solution to theaforementioned dilemma is simply to not allow a conversation 82 in an RMenvironment, or at least to not include RM-protected originating emails44 in conversations 82. Of course, such a solution is overly broad andis not feasible for reasons that should be apparent, not the least ofwhich is that users typically want conversations 82 to appear in theiremails 44.

Accordingly, in one embodiment of the present invention, and as seen inFIG. 15, each originating email 44 in the conversation 82 of an omegaemail 44 appears in the body 83 of the omega email 44 as a body object84 that is rights managed according to the RM properties of suchoriginating email 44. Note that such a body object 84 may be any type ofbody object without departing from the spirit and scope of the presentinvention. Such a body object 84 is known or should be apparent to therelevant public and therefore need not be described herein in anydetail.

For example, the body object 84 for a particular originating email 44within an omega email 44 may in essence be the corresponding originatingemail 44 with the RM properties thereof, except that the body 83 of suchoriginating email 44 is set forth within the omega email 44, and has itsown rights data 50. Of course, if such originating email 44 itselfcontains a conversation 82 of originating emails 44, such conversation82 is stripped out and the originating emails 44 thereof appearseparately in the omega email 44 at issue as other body objects 84thereof.

Thus, a recipient of the omega email 44, which is in turn rightsmanaged, can render each originating email 44 in the conversation 82 ofthe omega email 44, but only if such recipient has rights to render theomega email 44 and also rights to render the originating email 44 atissue. As a result, it may be the case that one recipient has rights torender some of the originating emails 44/body objects 84 but not others,while another recipient has rights to render all of the originatingemails 44/body objects 84.

As should now be appreciated, in the one embodiment of the presentinvention, the body objects 84 of originating emails 44 appear seriallyin the omega email 44, usually in reverse chronological order. In analternative embodiment, however, the conversation 82 of an omega email44 appears as a single body object 84 therein, and the body object 84 ofeach originating email 44 in the conversation 82 is nested within a bodyobject 84 of a chronologically next originating email 44. In such case,then, a recipient of the omega email 44, which is in turn rightsmanaged, can render each originating email 44 in the conversation 82 ofthe omega email 44, but only if such recipient has rights to render theomega email 44 and all intervening originating emails 44. As a result,the lack of rights to render one originating email 44 in theconversation 82 prevents the recipient from rendering allearlier/further nested originating emails 44 in the conversation 82.

Note that the use of serial body objects 84 has an advantage over nestedbody objects 84 in that a serially appearing body object 84 can ineffect be split into two sub-objects 84. Such splitting is especiallyuseful in the case where a comment or note is to be inserted into a bodyobject 84 in an in-line manner. Note, too, that the comment may itselfbe a body object 84 that is RM-protected.

Significantly, although the use of a body object 84 has heretofore beendescribed in terms of an email 44, such body object 84 may also beemployed in connection with any type of document, including document 62of FIG. 10, document 74 of FIG. 12, and the like, as is shown in FIG.16. Thus, by using body objects 84 within the body 83 of a document 62,74, the document 62, 74 may have RM protection, and parts of thedocument 62, 74 may have further RM protection. Alternatively, it may bethe case that the document 62, 74 itself has no RM protection, but thatvarious sensitive parts of the document 62, 74 have RM protection.

Note that at least some of the body objects 84 within an email 44, adocument 62, 74, or otherwise, may share a common bind ID. Accordingly,and as should be appreciated, a license 36 for one of the bind IDsharing body objects 84 may also be employed for all other of the bindID sharing body objects 84.

Decommissioning an RM Server 54

As should now be appreciated, in a typical RM protection scheme as thusfar disclosed herein, protected content 32 is encrypted according to acryptographic key, and the rights data 50 for the protected content 32includes a decryption key (KD) for decrypting the encrypted content 32,where (KD) is encrypted according to a public key of an RM server 54(PU-RM) operated by or on behalf of the organization to result in(PU-RM(KD)). Thus, only the RM server 54 having the private key (PR-RM)corresponding to (PU-RM) can apply same to (PU-RM(KD)) from the rightsdata 50 to obtain (KD), and then deliver (KD) in the form of a license36 that is bound to the protected content 32.

A dilemma, arises, however in the situation where the RM server 54 with(PR-RM) is decommissioned, so that such RM server 54 no longerparticipates in creating and enforcing RM protection for protectedcontent 32. As may be appreciated, reasons for decommissioning an RMserver 54 are many and varied and can include a determination that theRM server 54 being decommissioned is obsolete or otherwise no longerworthy of participating in the RM protection scheme, a desire in generalto no longer perform RM protection and enforcement, and the like.

At any rate, by decommissioning the RM server 54, all protected content32 protected according to (PU-RM) for the decommissioned RM server 54can no longer be licensed by such RM server 54. Without such license 36and (KD) for the protected content 32 therein, and as should beappreciated, the protected content 32 can not ever be decrypted by (KD),even for an individual who would have rights to render the protectedcontent 32 as determined by the rights data 50 therefor.

Accordingly, in one embodiment of the present invention, when an RMserver 54 is decommissioned, functionality is set into place to allowall content 32 protected according to the decommissioned RM server 54 tobe permanently stripped of RM protection and to be saved in a decryptedor ‘naked’ state. In particular, and turning now to FIG. 17, a method ofstripping the RM protection from a piece of protected content 32 basedon the corresponding RM server 54 being decommissioned is shown.

Preliminarily, and as may be appreciated, the RM server 54 is in factdecommissioned by being set into a decommission mode (step 1701).Principally, in such decommission mode, the RM server 54 no longerissues a license 36 in response to a request therefor in connection witha piece of protected content 32. Instead, the RM server 54 issues acontent key (KD) in response to a decommission request in connectionwith a piece of protected content 32. Moreover, inasmuch as (KD) is tobe employed to permanently strip the protected content 32 of RMprotection, such (KD) need not even be sent to the requester in aprotected form.

At or about the time the RM server 54 is set into the decommission modeas at step 1701, each user is notified that the RM server 54 has beendecommissioned (step 1703), and the user stores such notification in anyappropriate location of the computing device 34 thereof (step 1705),such as for example a registry or other data store. Accordingly, eachtime the individual attempts to render a piece of content 34 (step1707), the piece of content 34 is first examined to determine the RMserver 54 that can issue a license 36 for such content 34 (step 1709),and the storage location of the computing device 34 is then checked forany decommission notification for the determined RM server 54 (step1711). If no such decommission notification is found, the renderingprocess continues in a manner such as that shown in FIG. 9, where alicense 36 that allows such rendering is obtained from an RM server 54or is found on the computing device 34.

However, if the decommission notification for the determined RM server34 is found, the trusted component 38 on the computing device 34 makesthe aforementioned decommission request to the RM server 34 for thecontent 32 (step 1713). As may be appreciated, the decommission requestis similar to a license request in that the RM server 36 is sent therights data 50 corresponding to the protected content 32. Here, though,the RM server merely retrieves (KD) from the rights data 50 (step 1715)by applying (PR-RM) to (PU-RM(KD)) from the rights data 50, and returnsthe retrieved (KD) to the requester (step 1717). Again, such (KD) neednot be protected, although such protection may be applied withoutdeparting from the spirit and scope of the present invention. Uponreceiving (KD), the requester applies same to the protected content 32to reveal the content in a naked form without any RM protection (step1719), and then may save the content in the naked and non-protected form(step 1721).

Note that a nefarious user may cause a decommission request to be sentto a non-decommissioned RM server 54 in an attempt to obtain a (KD).However, the non-decommissioned RM server 54 should ignore such adecommission request because the non-decommissioned RM server 54 has notbeen set into decommission mode.

In an alternate embodiment of the present invention, the user need notbe notified that the RM server 54 has been decommissioned as at step1703. Instead, in response to a license request made to a decommissionedRM server 54, the RM server 54 merely retrieves and returns (KD)) as atsteps 1715 and 1717. Of course, without such a notification, the userwill continue to employ already-obtained licenses 36 from thedecommissioned RM server 54.

Conclusion

The programming necessary to effectuate the processes performed inconnection with the present invention is relatively straight-forward andshould be apparent to the relevant programming public. Accordingly, suchprogramming is not attached hereto. Any particular programming, then,may be employed to effectuate the present invention without departingfrom the spirit and scope thereof.

In the present invention, a rights management (RM) and enforcementarchitecture and method allow the controlled rendering of arbitraryforms of digital content, where such control is flexible and definableby the content owner/developer of such digital content. The architectureallows and facilitates such controlled rendering, especially in anoffice or organization environment or the like where documents are to beshared amongst a defined group of individuals or classes of individuals.Such architecture allows rights-managed email 44, propagating RMprotection to attachments 52 of RM-protected email 44, acquiringdecryption keys for RM-protected email 44, rights-managed documents 62,dynamic application of RM protection to a document 74 in a documentstore 72, RM-protected email conversations 82, decommissioning an RMserver 54, and the like.

It should be appreciated that changes could be made to the embodimentsdescribed above without departing from the inventive concepts thereof.It should be understood, therefore, that this invention is not limitedto the particular embodiments disclosed, but it is intended to covermodifications within the spirit and scope of the present invention asdefined by the appended claims.

1. A method of propagating rights management (RM) protection to an emailand to an attachment of the email, the attachment comprising anRM-protectable document, the method comprising: authoring the email withthe RM-protectable attachment; generating a content key (KD); generatinga bind ID; firstly applying RM protection to the RM-protectableattachment of the email based on the generated (KD) and the generatedbind ID; attaching the RM-protected attachment to the email; secondlyapplying RM protection to the email with the attached RM-protectedattachment based on the generated (KD) and the generated bind ID;wherein the RM-protected email and the RM-protected attachment thereofshare the generated (KD) and the generated bind ID such that a licenseobtained for the RM-protected email and having therein the generatedbind ID and the generated (KD) can be applied to render the RM-protectedemail and also the RM-protected attachment thereof.
 2. The method ofclaim 1 further comprising: protecting (KD) to an RM server so that allrequests for a license corresponding to the item are directed to such RMserver; and generating rights data including the protected (KD) and thegenerated bind ID and setting forth each entity that has rights withrespect to the RM-protected email and the RM-protected attachmentthereof and for each such entity a description of such rights; andwherein applying RM protection to each item comprises: encrypting theitem with (KD) to form (KD(item)); and attaching the rights data to thecorresponding (KD(item)) to form a package containing the item in anRM-protected form, whereby the signed rights data from the package forany item may be employed to obtain the license for the RM-protectedemail and the RM-protected attachment thereof, such license thusincluding the bind ID of the signed rights data and being bound to theRM-protected email and the RM-protected attachment thereby.
 3. Themethod of claim 2 further comprising submitting the generated rightsdata for signing and receiving signed rights data based thereon, wherebythe signed rights data is tamper-resistant in that any changes to thesigned rights data will cause the signature to fail to verify, andwherein attaching the rights data comprises attaching the signed rightsdata.
 4. The method of claim 3 wherein submitting the rights data forsigning comprises submitting the rights data to the RM server forsigning.
 5. The method of claim 2 wherein protecting (KD) comprisesencrypting (KD) with a public key of the RM server to result in(PU-RM(KD)) such that only the RM server with a corresponding privatekey (PR-RM) can decrypt (PU-RM(KD)) to reveal (KD).
 6. The method ofclaim 2 wherein attaching the rights data comprises concatenating thesigned rights data with the corresponding (KD(item)) to form a packagecontaining the item in an RM-protected form.
 7. An email having anattachment, the email and the attachment being rights management (RM)protected, the attachment of the email being RM-protected based on aparticular content key (KD) and a particular bind ID, the email with theRM-protected attachment itself being RM-protected based on theparticular content key (KD) and the particular bind ID, wherein theRM-protected email with the RM-protected attachment therein share theparticular (KD) and the particular bind ID such that a license obtainedfor the RM-protected email and having therein the generated bind ID andthe generated (KD) can be applied to render the RM-protected email andalso the RM-protected attachment therein.
 8. The email of claim 1wherein the RM protection for each item comprises the item beingencrypted with (KD) to form (KD(item)) and having attached theretocommon rights data to form a package containing the item in anRM-protected form, the common rights data including the particular bindID and the particular (KD) protected to an RM server so that allrequests for a license corresponding to the item are directed to such RMserver, and setting forth each entity that has rights with respect tothe RM-protected email and the RM-protected attachment thereof and foreach such entity a description of such rights, whereby the rights datafrom the package for any item may be employed to obtain the license forthe RM-protected email and the RM-protected attachment therein, suchlicense thus including the bind ID of the signed rights data and beingbound to the RM-protected email and the RM-protected attachment thereby.9. The email of claim 8 wherein the common rights data comprises rightsdata submitted for signing and received as signed rights data basedthereon, whereby the signed rights data is tamper-resistant in that anychanges to the signed rights data will cause the signature to fail toverify.
 10. The email of claim 9 wherein the rights data is submitted tothe RM server for signing.
 11. The email of claim 8 wherein (KD)protected comprises (KD) encrypted with a public key of the RM server toresult in (PU-RM(KD)) such that only the RM server with a correspondingprivate key (PR-RM) can decrypt (PU-RM(KD)) to reveal (KD).
 12. Theemail of claim 8 wherein the rights data is concatenated with thecorresponding (KD(item)) to form a package containing the item in anRM-protected form.
 13. A computer-readable medium having stored thereoncomputer-executable instructions for performing a method of propagatingrights management (RM) protection to an email and to an attachment ofthe email, the attachment comprising an RM-protectable document, themethod comprising: authoring the email with the RM-protectableattachment; generating a content key (KD); generating a bind ID; firstlyapplying RM protection to the RM-protectable attachment of the emailbased on the generated (KD) and the generated bind ID; attaching theRM-protected attachment to the email; secondly applying RM protection tothe email with the attached RM-protected attachment based on thegenerated (KD) and the generated bind ID; wherein the RM-protected emailand the RM-protected attachment thereof share the generated (KD) and thegenerated bind ID such that a license obtained for the RM-protectedemail and having therein the generated bind ID and the generated (KD)can be applied to render the RM-protected email and also theRM-protected attachment thereof.
 14. The medium of claim 13 wherein themethod further comprises: protecting (KD) to an RM server so that allrequests for a license corresponding to the item are directed to such RMserver; and generating rights data including the protected (KD) and thegenerated bind ID and setting forth each entity that has rights withrespect to the RM-protected email and the RM-protected attachmentthereof and for each such entity a description of such rights; andwherein applying RM protection to each item comprises: encrypting theitem with (KD) to form (KD(item)); and attaching the rights data to thecorresponding (KD(item)) to form a package containing the item in anRM-protected form, whereby the signed rights data from the package forany item may be employed to obtain the license for the RM-protectedemail and the RM-protected attachment thereof, such license thusincluding the bind ID of the signed rights data and being bound to theRM-protected email and the RM-protected attachment thereby.
 15. Themedium of claim 14 wherein the method further comprises submitting thegenerated rights data for signing and receiving signed rights data basedthereon, whereby the signed rights data is tamper-resistant in that anychanges to the signed rights data will cause the signature to fail toverify, and wherein attaching the rights data comprises attaching thesigned rights data.
 16. The medium of claim 15 wherein submitting therights data for signing comprises submitting the rights data to the RMserver for signing.
 17. The medium of claim 14 wherein protecting (KD)comprises encrypting (KD) with a public key of the RM server to resultin (PU-RM(KD)) such that only the RM server with a corresponding privatekey (PR-RM) can decrypt (PU-RM(KD)) to reveal (KD).
 18. The medium ofclaim 14 wherein attaching the rights data comprises concatenating thesigned rights data with the corresponding (KD(item)) to form a packagecontaining the item in an RM-protected form.
 19. A computer-readablemedium having stored thereon a data structure comprising an email havingan attachment, the email and the attachment being rights management (RM)protected, the attachment of the email being RM-protected based on aparticular content key (KD) and a particular bind ID, the email with theRM-protected attachment itself being RM-protected based on theparticular content key (KD) and the particular bind ID, wherein theRM-protected email with the RM-protected attachment therein share theparticular (KD) and the particular bind ID such that a license obtainedfor the RM-protected email and having therein the generated bind ID andthe generated (KD) can be applied to render the RM-protected email andalso the RM-protected attachment therein.
 20. The medium of claim 19wherein the RM protection for each item comprises the item beingencrypted with (KD) to form (KD(item)) and having attached theretocommon rights data to form a package containing the item in anRM-protected form, the common rights data including the particular bindID and the particular (KD) protected to an RM server so that allrequests for a license corresponding to the item are directed to such RMserver, and setting forth each entity that has rights with respect tothe RM-protected email and the RM-protected attachment thereof and foreach such entity a description of such rights, whereby the rights datafrom the package for any item may be employed to obtain the license forthe RM-protected email and the RM-protected attachment therein, suchlicense thus including the bind ID of the signed rights data and beingbound to the RM-protected email and the RM-protected attachment thereby.21. The medium of claim 20 wherein the common rights data comprisesrights data submitted for signing and received as signed rights databased thereon, whereby the signed rights data is tamper-resistant inthat any changes to the signed rights data will cause the signature tofail to verify.
 22. The medium of claim 21 wherein the rights data issubmitted to the RM server for signing.
 23. The medium of claim 20wherein (KD) protected comprises (KD) encrypted with a public key of theRM server to result in (PU-RM(KD)) such that only the RM server with acorresponding private key (PR-RM) can decrypt (PU-RM(KD)) to reveal(KD).
 24. The medium of claim 20 wherein the rights data is concatenatedwith the corresponding (KD(item)) to form a package containing the itemin an RM-protected form.